TABLE VI 


ASSOCIATIONS IDENTIFIED IN THE LITERATURE ABOUT BUG REPORTS. 





Association 


Rationale 





LackO f Knowledge 
— BugReport 


Insufficient domain and linguistic knowledge 
are presented as possible human root 
causes for software defects [36]. 





LackTechK nowledge 
— BugReport 


Insufficient programming and strategy 
knowledge and failure to catch the specific 
feature of the problems are mapped as 
possible human root causes for software 
defects [36]. 





RequiremProblem 
— BugReport 


Requirement management problems and a 
misunderstanding of requirements and 
design specifications are reported as possible 
human causes of software defects [36]. 





Overcon fidence 
— BugReport 


Overconfidence and confirmation bias 
contributes to evaluation errors 
and software defects [36]. 














TABLE V ; Interruptions and other kinds of inattention 
Inattention > : 
ASSOCIATIONS IDENTIFIED IN THE LITERATURE ABOUT CI AND BugReport are reported as possible human causes 
SOFTWARE QUALITY VARIABLES. JEVER, of software defects [36]. 
Communication Communication problems lead to expression 
Association Rationale — BugReport and comprehension errors [36]. 
Projects presents more resolved issues ConfigManagement | Configuration management problems 


CI > BugResolution 


and bugs after adoption of CI [28]. 


— BugReport 


lead to process errors [36]. 





CI is related to an increasing in the 


Tools problems like compiler induced defects 














number of issues closed by period, De t are possible root causes of software 
CI > ResolutionTime helping to spend less time debugging gep defects [36]. 
and more time adding features CodeSmells — 
[29], [30]. BugReport Code smells on the occcurrence of bugs [37]. 
CI teams discover more bugs than NumberOf Forks — | The number of forks has an association 
CI > BugReport see teams, and CI projects present Bug Report with an increase in bug reports [26]. 
ewer defects than no-CI projects Proj Project age has a significant negative effect 
roj Age > 
[26], [27]. on the count of bugs reported by core 
BugReport 


CI > Transparency 


CI is associated with a transparency 


increase, facilitating collaboration [34]. 


developers [26]. 








CI + Communication 


The general discussion, the number 
of line-level review comments, and 
change-inducing review comments 
tend to decrease after CI adoption 
without affecting pull request 
activity [35]. 


ProjPopularity > 
BugReport 


Project’s popularity has a significant negative 
effect on the count of bugs reported by core 
developers [26]. 





QuantIssues > 
BugReport 


The number of non-bug issue reports has a 
significant and positive effect on the 
response [26]. 








CI > Overcon fidence 


CI developers are reported as 
suffering from a false sense of 
confidence (when blindly trusting 
the tests) [31], [32]. 





TestsV olume > 
BugReport 


The size of test files has a negative effect on 
bug reports [26]. 














CI > TechnicalChallenges 





Configuring the build environment, 
the tools, and practices impose 
challenges for CI teams [31], [33]. 











TABLE VII 
ASSOCIATIONS IDENTIFIED IN THE LITERATURE ABOUT BUG 
RESOLUTION. 
Association Rationale 





InternalQuality > 
BugResolution 


Elements of InternalQuality, such as 
maintainability, analysability, changeability, 
stability, testability, project volume, 
duplication, unit size, unit complexity, 

and module coupling, present significan 
correlation with defect resolution 
efficiency [36]. 





Communication > 
Bug Resolution 


Human and data elements such as comments, 
severity, product, component, among others, 
can improve the performance of bug 
resolution [39]. 








IssuePriority > 
BugResolution 





Priority and severity are non-textual factors 
of a bug report that enhance the capability 
of bug resolution [39]. 











ASSOCIATIONS IDENTIFIED IN THE LITERATURE ABOUT THE RESOLUTION 


TABLE VIII 








TIME. 
Association Rationale 
IssueT ype + Issue fixing times are different for 
ResolutionTime different issue types [40], [41], [43], [44]. 





Communication > 
ResolutionTime 


The number of comments and the max 
length of all comments in the bug reports 
impact the resolution time. Bugs with little 
discussion tend to be resolved quickly 
[42], [43]. 





IssuePriority > 
ResolutionTime 


The severity of a bug report influences 
the delay before fixing it. As high the 
severity level, the fewer the delay [43]. 





CommitSize > 
ResolutionTime 


The size of code churn (number of methods) 
impacts the delay before fixing a bug 
report [43]. 


TABLE X 


CI ASSOCIATIONS CATALOGED AMONG THE LITERATURE FROM THE 
PERSPECTIVE OF TEST PRACTICES. 








OperateSystem — 
ResolutionTime 


The median delay before fixing a bug found 
on Linux is shorter than other OS [43]. 


Association 


Rationale 











IssueDescription + 
ResolutionTime 





Increasing the literal length of the bug 
report description can increase delay 
until the team checks it as resolved [43]. 


AutomatedTests + 
BugReport 


Automated tests are related to improved 
product quality in terms of fewer defects in 
the software [46]. 











TABLE Ix 


IINTERNAL ASSOCIATIONS CATALOGED AMONG THE LITERATURE 
REGARDING THE DISCOVERED VARIABLES. 


AutomatedTests —> 


Automated tests are related to high coverage 








CodeCoverage of code [46]. 

AutomatedTests —> Automated tests are related to reduced 
WorkTime testing time [46]. 

AutomatedTests —> Automated tests are related to increased 
Con fidence confidence in the quality of the system [46]. 





AutomatedTests + 


Automated tests are related to the less 
human effort that can be redirected for 














Human f fort other activities [46]. 

AutomatedTests —> Automated tests are related to a reduction in 
Cost cost [46]. 

AutomatedTests + Automated tests are related to increased fault 
Bug Detection detection [46]. 

AutomatedT ests > Automated tests require different skills to 
TechnicalChallenges | implement them effectively [47]. 
LackTechKnowledge | The skills level of testers could be a 


— AutomatedTests 


hindrance to test automation [47]. 





Stability > 


The stability and maturity of the software 
under test affect the maintenance effort 











Association Rationale 
IssueT ype > The issue type is associated with the size 
CommitSize of the code churn [45]. 








IssueT ype > 
Engagement 


Developers tend to spend more effort 
engaging with one another regarding new 
features and software extensions than 

in defects [41]. 











TechnicalChallenges of tests [47]. 

Design > Designing tests with maintenance in mind, 
Test Reusability they can be repeated frequently [46]. 

Test Repetition > When repeating tests, they are more reliable 
Reliability than single executions [46]. 

Proj Age > The number, coverage, and maturity of 
AutomatedT ests automated tests increase with time [48]-[51]. 








IssueT ype > 
InfoSharing 


Developers tend to share more information 
on defects and enhancements than 
support tasks [41]. 





IssueT ype > 


A higher number of comments is associated 








Communication with enhancements and defects [41]. 
IssueT'ype > There is an association between the 
Dif ficultyLevel difficulty of a change and its type [44]. 
i The maturity of the tools, infrastructure, 
Stability > d CI activities i hall 
TechnicalChallenges an activities imposes challenges 








to practitioners [33]. 











TABLE XI 


CI ASSOCIATIONS CATALOGED AMONG THE LITERATURE FROM THE 
PERSPECTIVE OF BUILD PRACTICES. 











Association Rationale 

BuildHealth > Broken builds lead to loss of time by freezing 
WorkTime development and tests [52]. 

BuildHealth > Broken builds lead to work blockage, which 
MergeConflicts in turn leads to merge conflicts [53]. 





TeamSize > 
BuildHealth 


The team size relates to build breakage. 
Shorter teams tend to break fewer than 
larger ones [52]. 





MultipleW orkspace 
— BuildHealth 


Maintaining multiple physical structures for 
multiple branches is associated with more 
build breakage [52]. 





Developer Role + 


There is a statistical difference in build 





BuildHealth breakage among different role groups [52]. 
CommitSize > The size of the changes is related to a higher 
BuildHealth probability of build failure [52], [54], [55]. 





CommitT ype > 
BuildHealth 


The commit type (such as features and bugs) 
and the contribution model (e,g., pull request 
and push model) are associated with build 
breakage [52], [54], [55]. 





CommitMoment > 
BuildHealth 


There is an association between the moment 
of contributions and the rate of build 
breakage [52]. 





TeamDistribution 
— BuildHealth 


The geographical distance of the team 
members is associated with the build 
results [52]. 








Tools + The languages and their tools are related 
BuildHealth to different build breakage rates [56]. 
ExtraComplexity 


— BuildHealth 


Complex builds tend to break [53]. 





FlakyTests > 


Flaky tests favor the occurrence of build 








BuildHealth breakage [53], [55]. 

ContributorType — | Less frequent contributors tend to break 
BuildHealth builds less [55]. 

TimeToFiz > The time lost relates directly to a monetary 
Costs cost [52]. 





Communication > 
TimeToFia 


The feedback mechanisms and information 
speed affect the awareness of a broken build 
and the time to fix it [52]. 





Developer Role + 
TimeToFiz 


The developer role is associated with the 
time to fix a broken build [52]. 





CommitT ype > 


The characteristics of the branches and code 
access (e.g., isolated branches) are associated 








TimeT oP in with the time to fix a broken build [52]. 
IntegrationF req The integration frequency in the team affects 
—> TimeToFix the build fixing [52]. 

ProgramLanguage The programming language is related to the 


> TimeToFiz 


time spent to fix a broken build [56]. 





The understandability of the build failures 





KIRU NAC tana directly impacts the time needed to solve 
— TimeToFiz 

them [57]. 
BuildFailT ype The build failure types are associated with 


—> TimeToFiz 


different difficulty levels [57]. 





TestsV olume > 


Complex and time-consuming testing is a 


























CommitSize possible reason for large commits [53]. 
ContributorT ype — | The type of contributor (e.g., casual) relates 
CommitSize to the build breakage rate [58]. 
ContributorT ype — | The contributor type is related to the number 
AutomatedTests of automated tests [58]. 

Extracomplexity — | The complexity of the jobs is related to the 
ContributorT ype type of contributor in the projects [58]. 
CommitSize > Large commits are associated with merge 
MergeConflicts conflicts [53]. 

FixzTools > Fix support tools improves the 
ErrorUnder stand understandability of the build logs [57]. 
BuildFailT ype > The build failure type is associated with 
ErrorUnderstand different levels of understandability [57]. 








